Device-to-device (D2D) communication is a component of many existing wireless technologies, including ad hoc and cellular networks. Examples include Bluetooth and several variants of the IEEE 802.11 standards suite, such as WiFi Direct. These systems operate in unlicensed spectrum.
D2D communications as an underlay to cellular networks takes advantage of the proximity of communicating devices and enables devices to operate in a controlled interference environment. Typically, D2D communications share the same spectrum as the cellular system. For example, a D2D device may reserve some of its cellular uplink resources for D2D purposes. Allocating dedicated spectrum for D2D purposes, however, is an unlikely alternative because spectrum is a scarce resource and dynamic sharing between the D2D services and cellular services is more flexible and provides better spectrum efficiency.
A D2D device may send data using various transmission modes. These include unicast (i.e., a specific wireless device is the receiver), multicast (i.e., a group of wireless devices are the receiver—also referred to as groupcast), and broadcast (i.e., all wireless devices are receivers).
When cellular network D2D communication is unavailable, a D2D device may send data to another D2D device without prior arrangement. This reduces overhead and increases communication capacity, which is important in emergency situations. The source D2D device transmits data to one (unicast) or more (multicast/groupcast/broadcast) other D2D devices, without first verifying that the recipient devices are available and ready to receive the data. Such communication may be used for one-to-one or one-to-many communication, but it is particularly effective for multicast and broadcast transmissions and thus well-suited for broadcast and group communication. The communication may occur, for example, via PHY unicast/multicast/groupcast/broadcast transmissions. Even using PHY broadcast transmissions, higher layers may treat the transmissions as unicast, groupcast, or multicast. For example, in the MAC layer, multicast or even unicast addresses may be used. Or, alternatively, if using broadcast on both PHY and MAC, multicast or unicast IP addresses may be used at the IP layer.
One way to efficiently implement D2D communication is to use a scheduling assignment (SA) followed by a data transmission. SAs are control messages used for direct scheduling of D2D communication. SAs are transmitted by the user equipment (UE) that intends to transmit D2D data and they are received by the UEs that are potentially interested in the D2D data. SAs are transmitted on dedicated resources characterized by time and frequency, and are typically a sparse resource. SAs provide information useful to the receiver. For example, a receiving device may use an SA to decode the D2D data transmission associated with the SA (e.g., the resources for data transmission, the modulation/coding parameters, timing information, identities for the transmitter and/or receiver, etc.). Typically, but not necessarily, a D2D device transmits SAs prior to the actual data transmission so that a receiving D2D device is able to selectively receive data based on the content of the SAs. The data transmissions scheduled by a SA may be referred to as a “transmission pattern.”
D2D application scenarios include, among others, proximity services (ProSe) where devices detect their proximity and subsequently trigger different services (such as social applications triggered by user proximity, advertisements, local exchange of information, smart communication between vehicles, etc.). Other applications include public safety support, where devices provide at least local connectivity even in case of damage to the radio infrastructure.
A ProSe UE-to-network relay can extend the coverage of the network beyond the coverage of the eNB. A ProSe relay is a UE that performs the role of a relay. The ProSe UE-to-network relay function includes support for relaying of unicast traffic (uplink and downlink) between remote UEs that are not served by evolved UMTS terrestrial radio access network (E-UTRAN) and the network. The ProSe UE-to-network relay provides a generic L3 forwarding function that can relay any type of IP traffic, such as traffic for public safety communication. An example is illustrated in FIG. 1.
FIG. 1 is a block diagram illustrating an example wireless network including a proximity services UE-to-network relay. Remote UE 10b is in one-to-one direct ProSe communication with relay UE 10a over a PC5 layer 2 link. Relay UE 10a is in communication with eNB 20 over a Uu interface, which is in communication with a public safety system via an evolved packet core (EPC). Relay 10a forwards layer 3 traffic from remote UE 10b to eNB 20.
Establishing a link between remote UE 10b and eNB 20 via ProSe UE-to-network relay 10a includes three general steps: (1) setup of relay UE 10a; (2) E-UTRAN assisted relay discovery; and (3) establishment of a secure layer 2 link over PC5. When remote UE 10b receives instruction from eNB 20 to connect to a particular relay, remote UE 10b sends a layer 3 message (from ProSe Signalling Protocol) to associate itself with relay UE 10a. Relay UE 10a responds with the layer 3 message. Connection establishment between remote UE 10b and relay UE 10a uses the ProSe signalling protocol. An example of the PC5 protocol stack is illustrated in FIG. 2.
FIG. 2 is a block diagram illustrating the PC5 protocol stack between a remote UE and a relay UE. A remote UE, such as remote UE 10b illustrated in FIG. 1, communicates with a relay UE, such as relay UE 10A illustrated in FIG. 1, via the ProSe signalling protocol. The ProSe signalling protocol is on top of the PDCP, RLC, MAC, and PHY layers. The priority of a ProSe communication transmission is selected by the application layer based on criteria that are not in the scope of ProSe specifications.
To transmit the data received from remote UE 10b to eNB 20, relay UE 10a requests uplink resources from eNB 20. Remote UE 10b may support a variety of different services. Accordingly, the characteristics of the data relay UE 10b transmits may vary. However, relay UE 10a does not consider the type of service remote UE 10a is providing when relay UE 10a requests resources for relaying data to eNB 20. As a result, relay UE 10a may not request Uu resources for relaying data in the most efficient way.
For example, when a remote UE is running a voice over interne protocol (VoIP) service, the remote UE may transmit data bursts periodically to the eNB via the relay (e.g., a burst every 20 ms). A resource efficient method to relay intermittent data bursts uses semi-persistently scheduled (SPS) resources on the Uu interface. The relay UE, however, does not know that the remote UE is transmitting SPS-like data. As a result, when transmitting the data to the eNB, instead of using SPS resources, the relay UE requests resources for each data burst received from the remote UE. This can be both time and resource consuming. An example is illustrated in FIG. 3.
FIG. 3 is an example flow diagram illustrating allocation of Uu transmission resources. Remote UE 10b transmits periodical data (i.e., Data #1, Data #2, Data #3) to eNB 20 via relay UE 10a. For each burst (i.e., Data #1, Data #2, Data #3), relay UE 10a requests resources separately. For example, at step 30 relay UE 10a receives Data #1 from remote UE 10b. At step 32, relay UE 10a requests resources and receives resource grants from eNB 20. At step 34, relay UE 10a transmits Data #1 to eNB 20. These steps are repeated for each data burst (i.e., steps 36-40 for Data #2 and steps 42-46 for Data #3). Thus, after receiving each data burst, but before transmitting the data burst to the network, the relay UE must request and receive transmission resource grants.